Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/mint/l_1199/821

Internet Message Format | 1994-08-27 | 2.2 KB

From: [e-mail]
Subject: Re: [MINTOS] fs tree structure  (was: Re: MiNT goes UNiX, ... )
Date: Mon, 17 Jan 94 12:24:26 MET
In-Reply-To: <[e-mail]>; from "Michael Hohmuth" at Jan 14, 94 05:34:49 am

Michael Hohmuth writes:

> I'd like to propose not to go into too much detail in defining a "standard"
> for the file system layout.  Different distributions will handle things
> differently, so I don't see much sense in discussing at this time where
> particular binaries of particular flavours of Unix should live, especially
> since most programs are independent of their physical location.

 That's as long ok as you can either ensure there's only one program with
a given name in the search path, or all of them offer the wanted UNiX
functionality.

 If you've got two versions of `more' for example, one able to handle
things like 'this.my.file' and another which is not, than it's a question
of what path comes first if the next tool which needs `more' runs ok or
breaks.

 Guess you won't want each tools to do this check by its own each time
it uses other programs, so either you cleary define unique paths, or you
ensure that really every program shares your view of filenames etc...

> Identifying the standard locations of config files and single user
> executables and a basic layout for /var should suffice at this point, as
> these are most closely related to the function of a Unix-like system.

 Hmmm... New idea: Perhaps the `global' install programm should check each
executable in the whole tree for a symbol _unixmode or whatever, just like
_stksize is used for other purposes to check if all programs are supposed
to be ok. If the necessary filename conversion routines and other stuff
goes to the library, this one would be totally transparent to the user,
just like the _stksize stuff. Get the source, recompile it and you're right
on. This symbol could contain a version number of the standard the program
is able to deal with.

bye,
TeSche
--
PS: If the above written looks weird, then that's probably because it _IS_.
Torsten Scherer (Schiller, TeSche...), University of Bielefeld, Germany
==> [e-mail] / [e-mail] <==